From February 17 to 19th 2012, between 10 to 30 hackers met at IRILL's offices to squash as many bugs as possible for the Wheezy release. Besides about 42 pizzas, more than one hundred bugs (104 to be precise) have been fixed. Among them, 18 of them were fixed by removing old/unmaintained/deprecated packages from the Debian archive. In a great atmosphere, one of the most important achievements of this BSP was that Yada, a deprecated packaging helper, finally passed away thanks to the efforts of Cyril Brulebois. Thanks for all the contributors for making of this week end a success.

Back in October 2011, I blogged about the removal of the sun-java6 package from the Debian archive. Even if Openjdk 7 is just great, some corporations still need to use the non-free sun-java6 packages.
For perform this task, C dric Pineau and I brought back an old package from the archive called java-package. From the upstream release, for example jdk-6u*-linux-x64.bin (which the user will have download since Debian is no longer allowed to redistribute it), the command

make-jpkg ~/Downloads/jdk-6u31-linux-x64.bin

will generate a .deb which can be installed in the packaging system. Obviously, new upstream releases will NOT be automatically updated. This is far from perfect but it is temporary solution until everybody switch to the OpenJDK.

Recently, I have been working on a side project for Debian. The goal was to rebuild of the Debian archive (the distribution) with clang, a new C/C++ compiler. clang is now ready to build software for production (either for C, C++ or Objective-C). This compiler is providing many more warnings and interesting errors than the gcc suite while not carrying the same legacy as gcc.
This rebuild has several goals. The first one is to prove (or not) that clang is a viable alternative. Second, building a software with different compilers improves the overall quality of code by providing different checks and alerts. The result are detailed and explained here:
http://clang.debian.net/ Conclusions
When I had the idea to rebuild Debian with a new compiler, I was expecting many issues and bugs caused by clang but I have been surprised to notice that most of the issues are either difference in C standard supported, difference of interpretation or corner cases.
My personal opinion is that clang is now stable and good enough to rebuild most of the packages in the Debian archive, even if many of them will need minor tweaks to compile properly.
In the next few years, coupled with better static analysis tools, clang might replace gcc/g++ as the C/C++ compiler used by default in Linux and BSD distributions.
The clang developers are progressing very fast: 14.5% of the packages were failing with version 2.9 against 8.8% with version 3.0.
Several major steps in the clang adoptions have been made like chromium/chrome being built by default with clang, Xcode providing clang by default, FreeBSD working on the gcc -> clang switch, etc.
However, on the Debian point of view, one of the important step would be to make sure that clang manages all the Debian architecture/kernel (11 official, 6 unofficial)

Yesterday, I uploaded hdf5 1.8.8 in unstable. This new version, which has been available in experimental for a while, is a major step in the HDF5 packaging. For those who are using this package, besides the switch from version 1.8.6 to 1.8.8, the changes are the following:

• Since upstream is now trying to keep a consistent ABI/API, packages have been renamed from libhdf5-xxx-X.Y.Z (X, Y and Z being the version number) to libhdf5-xxx-7 (7 being the version of the soname)
• The package libhdf5-serial-* have been renamed to libhdf5-7 or libhdf5-dev
• Symbol files have been added for all the libraries.
• arm archs have also libhdf5-openmpi-dev
• Support of HURD, armhf & s390x
• Help is now up to date and the debian/html.tgz.uu removed (thanks to the source format v3.0, two source tarballs are now used)
• A new package hdf5-helpers which contains h5cc, h5c++ and h5fc has been introduced
• Fix many lintian warnings
• Java HDF has been updated to version 2.8

More information about the transition:
http://release.debian.org/transitions/html/hdf5.html TODO: Fix the FTBFS (Fail To Build From Sources) under sparc & ia64.

Next February, 17 to 19th, a Bug Squashing Party (BSP) is organized at IRILL offices (disclosure: I work for IRILL part time), close to Place d'Italie in Paris. The principle of a BSP is to gather Debian contributors to tackle a maximum of bugs in Debian. This event is also the opportunity for new potential contributors to meet Debian Developers or Maintainers. Numerous regular contributors will attend to this BSP and will help newcomers to fix their first bugs. For organization reasons, an inscription on the Debian wiki is mandatory. Non-Parisian can find a list of hostel close to the IRILL's offices.

Reading Sylvestre Ledru's announcement, that sun-java6 was removed from the archives, I'd like to point out, that the recommended immediate purge of any binary packages built by sun-java6 should be postponed until you did have time to check, that important applications are working for you with the OpenJDK implementation. I need to retain sun-java6-plugin until upstream bug #588 for icedtea-plugin is fixed. If you have equal requirements (using ELSTER is required by tax law for me), make sure everything works with OpenJDK/IcedTea, otherwise you need to fetch the latest shipped version from snapshot.debian.org or install something directly from Oracle. Now, as security issues were mentioned in Sylvestre's post, I'm NOT recommending to have sun-java6-plugin running in your browser on default. Just switch the Java plugins before you really need it. For Iceweasel you can (de-)activate plugins in the add-on manager's plugin tab. Apart from that I'd recommend to not surf with any scripting or plugins active at all, NoScript! is a great way to do this conveniently.

As said in one of my previous blog post, we, Debian, were going to remove sun-java6 packages from the archive once critical security issues would come. It was supposed to happen sooner and later and here we are. The version 29 (see the #645881 Debian bug) of the Oracle proprietary JVM has been released. It fixes some critical issues but, because of the DLJ removal, Debian is no longer able to distribute it. Unfortunately, we have no other choice than asking for a removal from the archive and promote the use of the openjdk 6 & 7.
The conclusion is:
apt-get --purge remove sun-java6-jre && apt-get install openjdk-7-jre

After a request from Olivier Berger, I developed the Removed packages feed for Debian. This feed lists packages removed from the Debian Archive. Debian removed packages on Identi.ca
Debian removed packages on Twitter
For more information about removed packages

For the story, due to license reasons, the version of Java packaged in Linux distributions is not the same as the one released on the official website.
Each time a new version of Java is was released, Sun/Oracle people are were publishing a other distro specific release available on a dedicated website. Since I have been maintaining sun-java6 packages for a year and half, I am following the rhythm releases (security is one of the reasons).
A few days ago, I pinged on Twitter Dalibor Topic, who is, AFAIK, the person in charge of this at Oracle, he replied with a blog post Retiring the DLJ. The main information from this blog post is:

[...] further Oracle JDK 6 (or Oracle JDK 7) releases on Linux and Solaris will not be provided under the DLJ [...]

Basically, that means that Linux distributions will not be able to package new releases of the proprietary JVM/JDK (including the latest update -27). The only release available in the Linux distro will be the OpenJDK. While I am glad to see Oracle pushing the free JDK, I am a bit concern by this sudden decision. There are still bugs (for example, with fonts, applets or other others issues) present in the OpenJDK which does not happen in the sun-java6 packages.
And also, as Andrew John Hughes said on Twitter, the Oracle proprietary JVM just lost one of the two freedoms it had (free to redistribute the software)... Moreover, many people are still using the proprietary JVM. For example, Debian popularity contest or Ubuntu Popularity Contest reports 836864 installations of sun-java6-jre against 749731 of openjdk-6-jre. The bottom line is, if you are aware of bugs present only in OpenJDK, please report them (on the Debian bug tracker, launchpad or as a comment of this blog post). We will report them upstream to make sure OpenJDK is as good as sun-java6. Edit: comments closed due to the spams... Drop me an email on sylvestre@debian.org. I will push them.

During the Debconf 11 in Bosnia, I took the time to implement the following Identi.ca feeds: http://identi.ca/debiannew/ - Show the new packages submitted for inclusion in the Debian Archive (low traffic: 10 notices per day)
http://identi.ca/debianbug/ - Show the feed of the new bugs (high traffic: 136 notices per day) They are also mirrored on Twitter:
http://twitter.com/debiannew
http://twitter.com/debianbug Don't hesitate if you want new Debian feeds added on Identica or Twitter.

Tom Marble and Guillaume Mazoyer gave a talk about Jigsaw Progress in Debian during DebConf11 in Banja Luka. Guillaume is a Google Summer of Code student mentored by Tom and Sylvestre Ledru. The project is about modularizing OpenJDK which replaces the old fashioned classpath by a modulepath that knows about versioned dependencies. It can reduce the memory footprint and the startup time for applications running in the JVM. It would be interesting to match Debian package versions to Jigsaw module versions. Debian could influence the JDK version 8 in this area. Upstream is already building Debian packages but they do not follow the Debian policy and do not use the Debian packaging tools. Guillaume has uploaded 2 packages (jtharness, jtreg) to Debian. These packages are needed to run the upstream testsuite which ships 3484 individual tests. More than 99% of them are working in Debian. There is a GIT repository of his Jigsaw work at http://anonscm.debian.org/gitweb/?p=pkg-java/jigsaw.git;a=summary. The slides of the talk are available at http://penta.debconf.org/dc11_schedule/events/718.en.html.

My flights tickets are booked so I guess:


I m really happy to go to Banja Luka. This will be my first DebConf and not my last I hope. I ll be there to meet incredible people that make Debian what it is but I will also give a talk with Tom Marble and Sylvestre Ledru about my Google Summer of Code project at Debian. This talk should be the 2011-07-30 at 15:00:00.

My internship is now finished, this means that I will be able to work on my GSoC project a lot more than the previous weeks. I hope to make some good progress in the next days.

This last 2 weeks, I was still studying how Jigsaw works. Even if there is no progress on the Jigsaw packaging I have done some packages that will help later.

I ve spend a lot of time trying to package JT Harness and JTReg.
I ve successfully built JT Harness using CDBS but I ve finally rewritten the package using only debhelper and javahelper. Javahelper was really useful to build JAR files, move them to the right directory, put the Javadoc in the right place as well as the examples. The Debian directory of JT Harness can be found on the Java team SVN.

svn co svn+ssh://$ SVN_USER @svn.debian.org/svn/pkg-java/trunk/libjtharness-java

The source package of jtharness build 2 binary packages: libjtharness-java and libjtharness-java-doc. You can see that by looking at the control file in the debian directory. There are some interesting files in this package, let s take a look at them.

First of all, some of the source files needed to be patched for the package to build. So to accomplish this, there is a couple of patches in debian/patches :

• dependencies.diff, used to locate JAR files in /usr/share/java , and,
• rxtx.diff, done by Tom Marble used to change some imports from javax.comm to gnu.io .

To generate these patches, I ve used the edit-patch command which is a really awesome tool. This command uses a temporary shell where we can edit files we want to patch. When the job is done, CTRL + D terminates the temporary shell and the patch is generated.

There are 4 interesting files which are used to build the binary packages and put the files in the right directories. These files are:

• rules,
• libjtharness-java-doc.install,
• libjtharness-java.jlibs, and,
• libjtharness-java-doc.javadoc.

Of course rules is the most important one. This file tells us how packages are built. A good thing is that rules is quite simple in the jtharness case.

#!/usr/bin/make -f
JAVA_HOME = /usr/lib/jvm/default-java

override_dh_auto_build:
ant -f build/build.xml

%:
dh $@ --with javahelper

We just tell where Java is and to use javahelper ( with javahelper). Overriding dh_auto_build is interesting because since the JT Harness uses Ant as build system we need to give to Ant where the build.xml file is. By default Ant is searching it in the current directory but in jtharness the file is in the build directory. Since the Ant build file is correctly written, the build generates JAR files, Javadoc and examples code. And libjtharness-java* files are here to put the generated things in the right places.
The job of libjtharness-java.jlibs is to tell where to find the JAR libraries. In this case, the intesresting JAR files were javatest.jar and jt-junit.jar . So in the .jlibs file we just give where those files are after being built.
The job of libjtharness-java-doc.javadoc is to tell where the Javadoc is and where to put it. So there is only one line that says the generated Javadoc is in jar-build/javadoc and put it in /usr/share/doc/libjtharness-java/api .
And finally, libjtharness-java-doc.install is used to move the examples. The syntax is same as libjtharness-java-doc.javadoc .

The JT Harness package can be found in Sid now thanks to Sylvestre Ledru who uploaded it for me. So the ITP bug that I created is now closed.

Building the package for jtreg is quite similar. In fact, it probably easier but I m still facing a problem. jtharness is just a library, jtreg does have main classes and generate some binaries. The difficulty here is to generate the man pages for the 2 generated binaries: jtdiff and jtreg. These 2 files are shell scripts which just use jtreg.jar with the correct parameters.

I tried several tools to generate the man pages of each script. Sadly, I can t find a way that does not causes any problems.
My first choice was to use help2man. This tool looked like to be perfect for the job. But I couldn t find how to launch the scripts correctly. The scripts needs jtreg.jar but they also need javatest.jar from the libjtharness-java package. The classpath cannot be set correctly due how the scripts are written. So to use help2man I ll probably have to patch and completely rewrite jtdiff.sh and jtreg.sh in the sources.
My second choice was to use txt2man. During the build of jtreg there is a usage.txt file which is generated and which can be used as a man page. txt2man can take this text file and output a man page based on the text. I thought it was working but when building the package, lintian threw some warnings about syntax errors in the man pages.

W: jtreg: manpage-has-bad-whatis-entry usr/share/man/man1/jtdiff.1.gz
W: jtreg: manpage-has-errors-from-man usr/share/man/man1/jtdiff.1.gz 292: warning [p 4, 3.3i]: cannot adjust line

Finally, few days ago I decided to try rst2man. This tool looks cool and easy to use. But the text that I have to convert into a man page is not a reStructured text so it cannot without patching the usage.txt file for example. I was going to do it but there is no such file in the sources of jtreg. Actually this file is generated during the build but the text had to come from somewhere. And it was from two properties files in the source code.
I m still looking for a good solution to generate the man pages. If someone has any idea just let me know

The debian packaging of jtreg is not in the Java team SVN yet because of the man pages problem. I opened an ITP bug so people know that someone is working on jtreg.

My goal for the next two weeks is to finish the jtreg package, understand how jpkg (which is supposed to create Debian packages) works in Jigsaw and write more examples using the modular JVM.

Hello Planet Debian reader.

And now you re thinking, who is this crazy guy who does not even know how to write English (is my sentence wrong?). My name is Guillaume Mazoyer and I am the Google Summer of Code student working on Jigsaw with Tom Marble and Sylvestre Ledru. I blog from France and I plan to write my GSoC reports right here.

Maybe you don t know what is Jigsaw yet. If so, go read this wiki page, you should be able to understand the goal of my project. Here is the description:

Since the beginning of Java, the JVM is a big virtual machine will all the features incorporated in it. This JVM provides many features which are useful in only limited areas (Corba) or which are not used at all in some contexts (AWT/Swing are useless for a web server).

The goal of the jigsaw project is to provide a modular JVM.

This will provide many improvements in the performance area (startup, solving of the dependencies, etc) but also the size of the dependencies.

There are already some works done by upstream (Oracle) but it does not complain to the Debian standards. The target is Java 8.

The goal is this Google Summer of Code project is to package the current development version of Jigsaw into Debian.

Please note that this project is not only about packaging. This will probably implies some developments and contributions to upstream (upstream is aware of this effort). Updating javahelper to manage specifities of Jigsaw could be considered.

I m pretty excited to work on this project and the work has already started. Can t wait to go deeper and enjoy working on two things that I love: Debian and Java.

Here is some updates on the LLVM world into Debian.
LLVM and CLANG getting better and better after each release. After some lag, it is now time to have all these packages up-to-date into the archive. Here is an update of their status in Debian:

• LLVM
  LLVM 2.8 and 2.9 are now available into the archive.
  For version 2.8, Matthias Klose deserves most of the credit.
  Version 2.9 is available in experimental. They both build pretty well on most of the architectures besides kfreebsd. It is on my TODO list.
• Clang. A C/C++ compiler.
  clang 2.8 and 2.9 are respectively available in unstable and experimental.
  These versions cover most of C/C++ specifications and more and more big software (Qt, Boost, Scilab, etc) succeed to be built with it. Like LLVM, it is available under most of the Debian architectures (but I haven't tested the quality of the ASM generated). clang can be used just like gcc. With most of software, calling configure/make with CC="clang" or CXX="clang" should be enought.
• * Dragonegg
  Dragonegg is a gcc plugin (llvm-gcc-4.5) which allows gcc to use optimizer and code generators of LLVM.
  It is now straightforward to use:
  
llvm-gcc -o foo foo.c
I have lighten the "contact" between the gcc version used to build the extension and the version used to run it.
  It required the exact same version of gcc (even if the sources say it is probably a too strong requirement). Now, a warning like this one is displayed:
  
Potential incompatible plugin version. GCC: 4.5.3. Expected: 4.5.2
Defines 'dragonegg_disable_version_check' as env variable to remove this warning
Please note that unexpected errors might occur.
If there is a better way to tackle this issue, I will be happy to hear it.
• llvm-defaults
  Last but not least, I uploaded llvm-defaults, a work of Arthur Loiret. This package allows a similar behavior to gcc-defaults. The installation of llvm will provide the default version of llvm.

Deprecated stuffs:

• llvm
  The llvm package has been removed. Actually, it was just the version 2.6 of llvm (see bug #625729). llvm (from llvm-defaults) is now providing the favorite version of llvm.
• llvm-gcc-4.2
  Upstream stopped the development of this plugin.
  It has been removed from the archive (see bug #626007) and dragonegg is taking the relay.
• llvm-snapshot
  llvm-snapshot (see bug #626083) followed the same direction as llvm-gcc-4.2
• llvm-2.7
  llvm-2.7 is still in the archive (see bug #626081) because of some reverse dependencies...

Hello fellow developers, The summer is over but I m happy to announce that this year s Summer of Code at Debian has been better than ever! This is indeed the 4th time we had the privilege of participating in the Google Summer of Code and each year has been a little different. This year, 8 of our 10 students succeeded in our (very strict!) final evaluations, but we have reasons to believe that they will translate into more long-term developers than ever, all thank to you. The highlight this year has been getting almost all of our students at DebConf10. Thanks again this year to generous Travel Grants from the Google Open Source Team, we managed to fly in 7 of our students (up from 3!). You certainly saw them, presenting during DebianDay, hacking on the grass of Columbia, hacking^Wcheering our Debian Project Leader throwing the inaugural pitch of a professional baseball game or hacking^Wsun-tanning on the tr s kitsch Coney Island beach. Before I give the keyboard to our Students, I d like to tell you that it will be the pleasure and honor of Obey Arthur Liu (yours truly, as Administrator) and Bastian Venthur (as Mentor) to represent Debian at the Summer of Code 2010 Mentors Summit on 23-24 October 2010, at the Google Headquarters in Mountain View. Like last year, we expect many other DDs to be present under other hats. We will be having 2 days of unconference on GSoC and free software related topics. We all look forward to reporting from California on Planet and soc-coordination@l.a.d.o! All of our students had a wonderful experience, even if they couldn t come to DebConf, that is best shared in their own voice, so without further ado, our successful projects: Multi-Arch support in APT by David Kalnischkies, mentored by Michael Vogt apt-get install MultiArch does mostly work now as most code is already merged in squeeze, but if not complain about us at deity@l.d.o! Still, a lot left on the todo list not only in APT so let us all add MultiArch again to the Release Goals and work hard on squeezing it into wheezy. Debbugs Bug Reporting and Manipulation API by David Wendt Jr., mentored by Bastian Venthur Hello, I m David Wendt, and I went to Debconf10 to learn more about the development side of Debian. Having used it since the 9th grade, I ve been intimately familiar with many of Debian s internals. However, I wanted to see the developers and other Debian users. At DebConf, I was able to see a variety of talks from Debian and Ubuntu developers. I also got to meet with my mentor as well as the maintainer of Debbugs. Content-aware Config Files Upgrading by Krzysztof Tyszecki, mentored by Dominique Dumont Config::Model is now capable of manipulating files using shorter and easier to write models. Thanks to that, packagers may start experiment with creating upgrade models. Further work is needed to support more complicated config files Dominique Dumont is working on DEP-5 parser, I ll shortly start working on a cupsd config file parser.
The best thing about DebConf10 is that every person I talked with knew what I was doing. I had a mission to get some feedback on my project. Everybody liked the idea of making upgrades less cumbersome. On the other side, it was my first visit to United States, so I decided to go on a daytrip on my own (instead of staying inside the building, despite heat warnings). I had a chance to visit many interesting places like Ground Zero, the UN headquarters, Grand Central Terminal, Times square and Rockefeller Center that was a great experience. Hurd port and de-Linux-ization of Debian-Installer by J r mie Koenig, mentored by Samuel Thibault Debconf10 was great! Among other people working on the installer, I met Aur lien Jarno from the Debian/kFreeBSD team and we worked together on a cross-platform busybox package. Besides, the talks were very interesting and I ve filled my TODO-list for the year.
For instance I learned about the Jigsaw project of OpenJDK, and how Debian would be the ideal platform to experiment with it. More generally, some people think Debian could push Java 7 forward and I d like to see this happen. Smart Upload Server for FTP Master by Petr Jasek, mentored by Joerg Jaspert I must say that it was great time for me in NY, I ve met and talked and coded with people from ftp-master team like Torsten Werner who helped me to push the project a bit further and with some other people who were looking forward to release of the tool which I hope they will use quite soon. Everybody interested, everybody excited, really cool place and time. And I can t forget the Coney Island beach and stuff, lot of fun, lot of sun;) Aptitude Qt by Piotr Galiszewski, mentored by Sune Vuorela Currently, development branches support full features searching, viewing extended package s informations, performing cache and packages operations. Code and GUI still require a lot of work which will be continued. Informations about further progress could be found on aptitude mailing list and repository rss channel. Debian-Installer on Neo FreeRunner and Handheld Devices by Thibaut Girka, mentored by Gaudenz Steinlin For me, DebConf 10 started at the airport, where Sylvestre Ledru (whom I didn t know of before) was wearing a GSoC 2007 t-shirt, that is, given the circumstances, almost equivalent to say I m a hacker, I m going to DebConf 10 .
I ve spent my time at the conference attending various talks, hacking, meeting DDs and other hackers (amongst others, my co-mentor Per Andersson, Paul Wise, Julien Cristau, Christian Perrier, Cyril Brulebois, Martin Michlmayr, Colin Watson and Otavio Salvadores who I have to thank for his patience while dealing with my questions), chatting, cross-signing keys, rushing to finish eating before 7pm, getting sunburnt, sightseeing (thanks, Arthur, for the lightning-fast tour of Manhattan!), and so on. Debian Developers and community, we count on you. See you next year! (cross-posted to debian-devel-announce@l.d.o and soc-coordination@l.a.d.o)

Science and Math Track at DebConf10 This year's DebConf10 (which is great, by the way) at Columbia University, New York will feature Tracks for the first time. We had a Community Outreach track on Debian Day (to be continued by more awesome talks over the rest of the week), a Java track on Monday and an Enterprise track yesterday. Tomorrow, Thursday afternoon, the S cience and Math track (which I am organizing) will take place in the Interschool lab on level 7 of Schapiro Center. The Track will start at 14:00 with a short welcome from me, followed by presentations of debian-science by Sylvestre Ledru and debian-math by David Bremner. At 15:00, Michael Hanke and Yaroslav Halchenko will present their talk on "Debian as the ultimate platform for neuroimaging research". This will be followed at 16:00 by three mini-talks on "New developments in Science Packaging". Adam C. Powell, IV will talk about MPI, Sylvestre Ledru will present linear algebra implementations in Debian and finally Michael Hanke and Yaroslav Halchenko will discuss the citation/reference infrastructure. At the end of track, the annual debian-science round-table will happen at 17:00, where David Bremner (mathematics), Michael Hanke (neuro-debian), Sylvestre Ledru (debian- science/pkg-scicomp), Adam C. Powell, IV (debian- science/pkg-scicomp) and myself (debichem) will discuss matters about cross-field debian-science and math related topics. If afterwards there are still outstanding matters to be discussed, we can schedule ad-hoc sessions for science or math matters on Friday or Saturday. See you at the science track tomorrow!

First, a quick news. Scilab 5.2.2 has been released a few days and he now available in the Debian archive (Debian Unstable for now).
It is mostly a performance improvements and bug fixes release. See the changelog. Second, for a second year, Scilab is part of the Google Summer of Code v2010. I am admin (and also mentor) this year again.
Google just released the list of accepted students. We have 9 students (against 7 last year). 2 are working on experimental projects, the other should have a finished result by the end of the GSoC. Extends Scilab UI Control - Han Dong
Extension of Scilab User Interface construction (uicontrol) by providing more elements (tree, image display, etc). Simulink import in Xcos - Jerzy Zagorski
Importation of most of the Simulink schemas from Xcos. Cumulative distribution function improvements - Michael Zhang
Improvement and extension of the current cumulative distribution functions (CFD) into Scilab. Metanet and Boost.graph - Bal a Rai evi
Extension of the Metanet capabilities in term of graphs by Boost.graph SOAP Client/server - Artem Glebov
Making available from Scilab both SOAP client and server capabilities as an ATOMS module. Database module + fuzzySQL - Igor Gridchyn
Allow to access to most databases systems from Scilab. Based on this work, the FuzzySQL will be introduced, a SQL extension to allow flexible conditions in queries. Python import - Baozeng Ding
Introduction of a mechanism to load and use Python code (objects in particular) from Scilab. Experimental projects:
Use Eigen into Scilab - Joseph Fahnbulleh
Base some components of the Scilab core code on the Eigen library which is a state-of-the-art C++ linear algebra library. This work will be a joint mentoring between Ga l Guennebaud from the Eigen team and Scilab R & D team. Hybrid Automata module - Ievgen Ivanov
Provide a convenient environment for direct modeling of hybrid automata in Scilab/Xcos.

• Surely, you already found out ftp-master is back.
• Andreas Barth wrote a good post about how to help the Debian release team.
• Bernd Zeimetz introduced the deb.li the Debian ShortURL Service, still in beta phase!
• Sylvestre Ledru blogged about an important update of the linear algebra libraries, BLAS and LAPACK, in Debian:
  • a refactoring of the ATLAS libraries (a BLAS implementation) with an upgrade to the version 3.8.3 fixing many issues
  • the switch between the different BLAS/LAPACK implementations is now way easier:
    http://wiki.debian.org/DebianScience/LinearAlgebraLibraries
• Some important deadlines are approaching:
  • April 9th, GSOC: student application deadline.
  • April 15th, Debian Project Leader Elections 2010 voting.
  • April 15th, DebConf: Early registration deadline if you want to be eligible for free food and accommodation and/or travel sponsorship
  • May 1st, DebConf: Event submission deadline. See also, DebConf important dates

In the numerical computing world, the cornerstones libraries are BLAS and LAPACK. They have been used in most of the numerical software for decades (like Scilab, R, numpy, OpenOffice with calc, etc). During that time, many implementations appeared to improve the performances taking advantages of clusters, multicore, SEE 1,2,3,4 , various levels of cache...
Between the reference BLAS (refblas) to an optimized one like ATLAS or MKL (Math Kernel Library by Intel - non-free), it is not rare to have a 15 factor. In Debian, we use by default the reference implementation of BLAS (168 reverse dependencies) and LAPACK (178 reverse dependencies). If the results are usually bad, they are pretty easy to use. What is hard to use, is switch between highly optimized libraries.
For now, the main one in the archive is ATLAS. ATLAS build process will launch many computations to know what will work best on the architecture. Results are usually excellent. 1) Upload of a refactoring of the ATLAS package.
I have been working on this for a while and after 19 uploads into Debian Experimental and I am happy (and kind of relief) to upload into debian unstable the release 3.8.3 of ATLAS. The new key elements in this release are:

• Package of the release 3.8.3 ... Long overdue
• Much more packages for recent architectures (sse3, core2sse3, etc)
• A simplified maintenance
• Easy to build a custom package: fakeroot debian/rules custom
• Easy upgrade to version 3.9.X when it is stable
• 12 bugs closed in Debian (including 4 RCs)
• 6 bugs closed in Launchpad.
• MMX optimized package removed

Note that, as before, all prebuilt binaries of ATLAS will be always slower than if you built them on the target architecture (but using Debian binary packages will save a few kilograms of Uranium). And one of most important feature is the capability to switch to any ATLAS implementation. 2) Switch between the different implementation
The problem in Debian (and Ubuntu) was that it was hard to switch between the ref BLAS/LAPACK and the optimized libraries. The user has to play with the LD_LIBRARY_PATH to use the various optimized packages and since there is no convention between the various distribution, the upstream developer has to develop crappy tricks to handle such things. It is why I implemented the following proposal: Handle different versions of BLAS and LAPACK. The main idea is to use the update-alternatives system to allow a quick and easy switch. For example:

# update-alternatives --config libblas.so.3gf 
There are 3 choices for the alternative libblas.so.3gf (providing /usr/lib/libblas.so.3gf).
  Selection    Path                                           Priority   Status
------------------------------------------------------------
* 0            /usr/lib/atlas-core2sse3/atlas/libblas.so.3gf   55        auto mode
  1            /usr/lib/atlas-base/atlas/libblas.so.3gf        35        manual mode
  2            /usr/lib/atlas-core2sse3/atlas/libblas.so.3gf   55        manual mode
  3            /usr/lib/libblas/libblas.so.3gf                 10        manual mode
# update-alternatives --config liblapack.so.3gf
There are 3 choices for the alternative liblapack.so.3gf (providing /usr/lib/liblapack.so.3gf).
  Selection    Path                                             Priority   Status
------------------------------------------------------------
* 0            /usr/lib/atlas-core2sse3/atlas/liblapack.so.3gf   55        auto mode
  1            /usr/lib/atlas-base/atlas/liblapack.so.3gf        35        manual mode
  2            /usr/lib/atlas-core2sse3/atlas/liblapack.so.3gf   55        manual mode
  3            /usr/lib/lapack/liblapack.so.3gf                  10        manual mode

Thanks to this, it is just trivial to switch from one to the other... Conclusion:
I just pushed the changes into Debian unstable for blas, lapack and atlas.
I have been testing a lot these deep modifications and I fixed all the problems that I found. However, in case I missed something, please report a bug...